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INTRODUCTION 


The  year  1962  has  brought  a  significant  change  to  the  way  in  which 
the  military  customer  has  specified  maintainability  (M)  require¬ 
ments  in  his  contracts, 

In  the  past,  maintainability  and  maintenance  requirements,  if  men¬ 
tioned  at  all,  were  generally  called  out  as  a  best  effort  item.  No 
criteria  were  specified  to  establish  even  a  minimum  base  for  this 
best  effort  work.  Contractors  were  free  to  interpret  the  contract 
requirement  in  any  manner  they  chose.  Since  a  rigid  interpretation 
generally  meant  time  and  money,  and  since  they  could  always  be 
sure  that  at  least  some  of  their  competitors  would  be  less  conscien¬ 
tious  than  themselves  about  this  innocuous  requirement,  it  was  gen¬ 
erally  easier  to  agree  to  best  effort  and  let  it  go  at  that.  Doing 
otherwise  often  priced  them  out  of  the  competition. 

Action  by  DOD'"  and  the  military  services  culminated  in  a  number  of 
maintainability  specifications  in  1962  and  drastically  changed  this 
earlier  approach  to  the  maintenance  problem.  Each  service  will 
publish  quantitative  requirements  for  maintainability.  The  object¬ 
ive  of  these  requirements  is  to  insure  t.  '  ^  M  is  considered  as  a 
design  parameter  and  that  M  considerations  are  factored  into  future 
systems  development  programs  along  with  the  traditional  consider¬ 
ations  of  engineering  performance  and  (more  recently)  reliability. 
Common  points  of  these  requirements  are  as  follows: 

1.  They  are  specified  in  quantitative  terms,  and  hence 
should  be  capable  of  being  predicted  in  advance,  measured 
and  evaluated  during  equipment  development,  and  subsequently 
demonstrated. 


Department  of  Defense  directive  3200.6  of  June  7,  1962  outlines 
the  reliability  and  maintainability  information  required  in  future 
Requirements  Documents  and  Technical  Development  Plans, 


1 


SP*216 


2.  They  are  derived  from  (and  bear  direct  relationship  to) 
the  mission  requirements  of  the  specific  system,  and 

3.  They  require  well  organized  well  planned,  and  well 
implemented  programs,  on  the  part  of  both  the  customer 
and  the  contractor  if  the  stated  quantitative  requirements 
are  to  be  met. 

One  basic  criterion  present  in  all  of  these  specifications  is  ”time’*. 

It  has  finally  been  officially  recognized,  for  example^  that  the 
"downtime'*  or  turn-around  time  criterion  is  an  important  element 
in  the  ability  of  a  system  to  accomplish  its  mission.  Further,  this 
particular  criterion  is  a  fundamental  measure  of  the  effectiveness 
of  the  maintenance  action,  since  it  can  be  combined  with  other  main¬ 
tenance  data  such  as  cost,  effort  and  resources  to  provide  appro¬ 
priate  indices  of  maintenance  efficiency.  Downtime  is  the  most 
direct  link  between  system  effectiveness  and  maintenance  action; 
it  is  not,  of  course,  the  sole  measure  of  the  efficiency  of  the  main¬ 
tenance  action. 


CURRENT  M  SPECIFICATIONS 

Examples  of  this  M  criterion  as  defined  in  four  important  military 
specifications  are  as  follows. 

1.  MIL-M-2651  2 -B(  USAF^  Maintainability  Requirements  for 

Aerospace  Systems  and  Equipment  (paragraph  6.  3.  1). 

"6.  3.  1  Maintainability  -  The  combined  qualitative  and 
quantitative  characteristics  of  materiel  design  and  instal¬ 
lation  which  enables  the  accomplishment  of  operational  ob¬ 
jectives  with  minimum  expenditures  including  manpower, 
personnel  skill,  test  equipment,  technical  data,  and  facilities 
under  operational  environmental  conditions  in  which  scheduled 
and  unscheduled  maintenance  will  be  performed.  Maintain¬ 
ability  is  effective  at  all  levels  of  maintenance  as  follows: 

"a.  Maintainability  (organizational)  -  The  capability 
of  an  equipment  to  be  returned  to  an  operational  status 
in  a  specified  period  of  time. 
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"b.  Maintainability  (field)  ^  The  capability  of  an  equip¬ 
ment  to  be  returned  to  a  serviceable  status  with  speci¬ 
fied  test  and  repair  equipment  within  a  specified  period 
of  time.''' 

"c.  Maintainability  (depot)  -  The  capability  of  an  equip¬ 
ment  to  be  overhauled  and  returned  to  a  serviceable 
condition  at  a  specified  percent  of  unit  cost 

2.  MI1j-M-23313  (BuShips)  Maintainability  Requirements  for 
Shipboard  and  Shore  Electronics  Equipment  and  Systems. 

”3.2  Maintainability  requirements  -  The  procuring  activity 
will  specify  an  equipment  repair  time  (ERT)  in  the  detailed 
equipment  or  systems  specification.  The  design  of  the  equip¬ 
ment  or  system  shall  be  such  that  the  geometric  mean  of  all 
active  repair  time  intervals  required  to  repair  independent 
failures  shall  not  exceed  the  specified  ERT.  Compliance 
with  this  requirement  will  be  verified  in  the  final  design  stage, 
and  in  the  preproduction  and  production  stages  ...” 

3.  XWR-30  (BuWeapons)  Weapons  Readiness  Achievement 
Program,  Part  III,  Section  I,  page  10  (Maintainability 
Requirements) 

"Mission  requirements,  such  as  availability  or  permissible 
M  (average)  and  M  (maximum)  downtime  of  the  end  article 
per  specified  period  shall  be  the  basic  criteria  for  the  pro¬ 
posed  maintainability  philosophy.  The  quantitative  require¬ 
ments  for  maintainability  shall  be  expressed  and  measured 
in  terms  of  mean  (M)  and  maximum  system  or 

equipment  downtime  ...” 

4.  SCC-4301B  (Army)  Maintainability  Design,  paragraph  3.  2.  1, 
Maintainability  Definition. 

”...  maintainability  is  defined  quantitatively  in  relationship  to 
its  relative  effect  in  each  of  five  consequence  areas:  Downtime, 
maintenance  time,  logistics  requirements,  equipment  damage 
and  personnel  injury. ” 

Note  that  downtime  requirements  are  not  in  themselves  sufficient- 
man  hours  effort,  cost,  and  resource  utilization  are  also  necessary 
considerations  in  any  maintainability  analysis  program. 
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DERIVATION  OF  PREFERRED 
SYSTEM  REQUIREMENTS 

With  this  background  we  can  now  describe  how  maintainability  re¬ 
quirements  may  be  derived  from  the  mission  of  the  system  and  how 
one  M  characteristic  is  related  to  other  system  characteristics. 

As  a  starting  point.  Figure  1  demonstrates  the  logical  steps  in  de¬ 
lineating  preferred  system  requirements.  Reading  from  the  top  of 
Figure  1,  general  operational  requirements  establish  the  context 
for  a  spectrum  of  missions  which  take  into  account  environmental 
and  geopolitical  considerations  as  well  as  economic  and  technical 
limitations  (for  example,  anti-ICBM  defense,  antisubmarine  war¬ 
fare).  A  specific  mission,  e„g  ,  antisubmarine  warfare,  can  then 
be  translated  into  its  specific  operational  requirements  through  ap¬ 
propriate  studies.  At  this  point  functional  mission  requirements 
can  be  derived.  Force  structure  analyses  and  cost-effectiveness 
studies  then  permit  selection  of  the  preferred  system  (say,  killer 
submarines  for  the  ASW  example)  from  an  array  of  synthesized 
alternatives  which  presumably  meet  these  functional  mission  re¬ 
quirements  . 

In  the  past,  the  "preferred”  system  has  most  often  been  defined 
directly  by  the  military  customer,  sometimes  without  exploratory 
studies  to  evaluate  alternatives  The  present  trend,  however,  is 
toward  broad  cost-effectiveness  analyses  of  alternative  system  con¬ 
figurations,  taking  into  account  the  full  operational  life  of  the  equip¬ 
ment  and  total  force  requirements,  prior  to  developing  hardware 
specifications  for  a  specific  system 

Figure  2  presents  a  context  for  considering  maintainability  require¬ 
ments  within  the  framework  of  the  total  weapons  system.  (Refer¬ 
ence  1  describes  this  context  and  an  appropriate  model  in  more 
detail.  )  Once  a  preferred  system  has  been  specified,  it  is  possible 
to  derive  quantitative  requirements  for  it  in  terms  of  performance 
and  operational  availability,  considering  specific  mission  require¬ 
ments  and  the  given  constraints  (e.g.  ,  technological  limitations, 
time,  resource  limitations,  cost).  Tradeoff  studies  between  per¬ 
formance  and  operational  availability  are  prerequisites  to  estab¬ 
lishing  intelligent  requirements  for  these  factors.  ^  After  oper¬ 
ational  availability  goals  are  established,  appropriate  quantitative 
requirements  for  system  reliability  and  maintainability  can  be 
developed  through  further  tradeoff  studies.'^  These  requirements 
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can  then  be  aDocated  from  system  to  subsystem  to  component  as 
explicit  design  objectives.  This  process  is  the  basis  for  translating 
mission  requirements  into  detailed  M  design  criteria. 


DE31IVATION  OF  M  REQUIREMENTS 

Figure  3  presents  a  graphic  interpretation  of  a  mission  profile  for 
a  hypothetical  missile  fire  control  system 

For  any  such  s^ystem  (and  generally  for  its  independent  functional 
subsystems)  a  "demand”  profile  {or  family  of  profiles)  can  be  de¬ 
rived  from  mis  sion  requirements.  Depending  on  the  specific  mis¬ 
sion,  certain  Hi  mitations  exist  on  the  operational  availability  per 
mission  cycles  on  the  maiximum  number  of  failures  per  mission 
cycle;  and  on  the  maximum  tolerable  downtime  per  failure.  If  these 
limitations  arc  not  exceeded,  the  system  will  meet  mission  require¬ 
ments;  if  they  are  exceeded,  it  will  not. 

Figure  4  show  graphically,  how  to  convert  operational  availability 
requirements  tc  specific  R  and  M  requirements  within  mission  con¬ 
straints.  Man/  combinations  of  R  and  M  requirements  can  be  ob¬ 
tained  for  a  gi\ren  availability  level.  For  example,  a  90  percent 
availability  le^cl  can  be  attained  through  a  failure  rate  of  two  fail¬ 
ures  per  mission-cycle  and  a  corresponding  downtime  of  60  minutes 
per  failure  instance.  The  same  90  percent  availability  can  also  be 
attained  by  a  failure  rate  of  ten  failures  per  mission  cycle  and  a 
downtime  of  12  minutes  per  failure.  If  both  of  these  alternatives 
are  tolerable  for  the  mission,  the  system  manufacturer  should  have 
that  much  latitude  in  meeting  the  availability  specification.  For 
example,  the  manufacturer  may  have  special  talent  in  the  develop¬ 
ment  of  automatic  test  or  troubleshooting  equipment  and  hence  could 
meet  the  specification  more  economically  by  reducing  downtime 
rather  than  in^proving  reliability.  Total  costs  should  be  investigated 
prior  to  such  a  decision,  of  course,  since  reliability  improvement 
is  a  one-time  #.feD  cost  that  can  mean  savings  in  maintenance  costs 
over  the  entire  program  length.'''  Cost  tradeoff  studies,  therefore, 
between  reliability  and  maintainability  requirements  are  necessary 
before  deriving  final  M  requirements."^ 


Note  that  the  s  e  savings  represent  at  least  the  minimum  dollar 
amount  that  can  be  justified  for  investment  in  RicD  reliability 
improvement  programs. 
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Figure  3.  Mission  Profile  for  Hypothetical  Missile  Squadron  039*9 u 
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Once  such  tradeoffs  are  made,  R  and  M  requirements  for  a  system 
can  be  spelled  out  as  shown  in  Table  1  This  table  shows  how  the 
three  factors  of  operational  availability,  reliability  and  maintain¬ 
ability  might  be  specified  for  our  hypothetical  fire  control  system: 


Table  1,  Hypothetical  Requirements  Allocation 


Specifi 

cations 

Required  Per¬ 
formance  Level 

System  Operational 
Requirements  Factors 

Base 

Time 

Avail 

Reli, 

Maint , 

Period 

1 

Max.  Level 

^Am 

— 

— 

^  T 

m 

2 

Max.  Level 

No.  of  non¬ 
consecutive 

failures 

.Ni 

Downtime 
per  fail¬ 
ure  ^  At^ 

*  1  day 

Specification  1.  This  specifies  average  operational  availability  (Am) 
of  the  system  for  the  prescribed  mission  and  performance  level 
(e.g.,  14  ready  missiles).  If  a  large  number  of  missions  were  made 
we  would  expect  the  attained  average  operational  availability  to  be 
close  to  this  number. 

This  particular  specification  does  not,  however,  take  into  account 
nor  restrict  the  fluctuations  about  the  expected  value  of  Am  which 
which  would  occur  on  individual  missions.  Further,  as  previously 
noted  it  does  not  impose  a  limit  on  tolerable  failures  per  unit  time 
(per  day  in  our  example)  or  on  tolerable  downtime  per  failure.  An 
additional  specification  (such  as  No  2)  must  be  used  if  mission 
analyses  have  indicated  the  need  for  these  restrictions. 

Specification  2.  This  limits  the  fluctuations  we  would  expect  about 
the  average  Am  noted  in  Specification  1  and  imposes  additional  R 
and  M  requirements  as  derived  from  mission  analyses.  This  speci¬ 
fication  can  be  interpreted  to  state  that  the  system  shall  be  able  to 
remain  at  the  specified  maximum  performance  level  for  not  less 
tha,n  (where  Aj  is  specified  availability  per  unit  time  — day).  It 
further  states  that  there  can  be  no  more  than  nonconsecutive 
failures  per  day  (failure  defined  as  less  than  specified  maximum 
performance)  and  the  downtime  per  failure  cannot  exceed  Atj.  Here 
we  introduce  R  and  M  requirements  for  the  first  time. 
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These  specifications  state  that  the  specified  performances  shall  be 
met.  This  can  be  interpreted  to  mean  that  the  probability  that  they 
are  not  met  on  a  particular  mission  is  to  be  negligible,  say  less  than 
one  percent.  The  acceptable  risk  of  not  meeting  requirements  on  a 
particular  mission  must  be  spelled  out  in  order  to  predict  and  verify 
whether  the  system  involved  meets  its  operational  requirements. 

Summarizing,  requirements  for  system  operational  availability  (in¬ 
cluding  its  components  of  reliability  and  maintainability)  should  con¬ 
sist  of  at  least  the  following  for  each  discrete  performance  level: 

1.  The  specified  average  operational  availability  per  mission 
cycle . 

2-  The  specified  minimum  operational  availability  per  unit 
time  (when  appropriate). 

3.  A  specified  maximum  tolerable  failure  rate  per  unit  time 
or  per  mission  cycle, 

4.  A  specified  maximum  tolerable  return  to  service  rate 
per  failure. 

5.  A  minimum  acceptable  probability  that  the  specified 
limits  will  be  exceeded  in  any  single  time  base. 

Whether  or  not  a  system  will  meet  such  requirements  can  only  be 
verified  by  a  well  planned  demonstration  program.  Such  a  program 
should  be  an  integral  part  of  the  overall  project  and  should  be  de¬ 
signed  to  accept  or  reject  the  hypothesis  that  the  system  meets  re¬ 
quirements.'*'  The  Air  Force,  as  noted,  is  currently  working  on 
requirements  for  such  a  demonstration  program. 


DISTRIBUTION  OF  DOWNTIME 

The  total  length  of  time  that  a  system  is  down  for  maintenance,  of 
course,  varies  statistically  from  one  failure  to  another.  Further, 
it  also  varies  for  repetition  of  a  given  failure  type  and  the  corres¬ 
ponding  repair  cycle. 


’J' Such  a  program,  of  course,  would  be  to  evaluate  both  the  intrinsic 
(designed  in)  capability  and  the  extrinsic  (such  as  those  influenced 
by  human  factors  and  the  operating  environment)  aspects  of  the 
system  in  question. 
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Analysis  of  experimental  data  on  system  downtimes  shows  that  the 
observed  range  of  variables  can  be  fitted  in  most  cases  by  a  log¬ 
normal  distribution.  ^  The  lognormal  is  a  distribution  in  which  the 
logarithm  of  the  distributed  variable  is  normally  distributed.  Tech¬ 
nical  details  of  the  parameters  involved  and  the  rationale  behind 
this  distribution's  applicability  are  contained  in  the  above  referenced 
report. 

The  importance  of  the  existence  of  an  appropriate  statistical  dis¬ 
tribution  to  describe  downtime  variations  to  the  designer  and  the  M 
engineer  should  not  be  overlooked.  It  provides  a  mechanism  for 
definitively  assigning  downtime  requirements  to  subsystems  and 
components.  For  example,  a  mean  or  expected  value  oan  be  speci¬ 
fied  for  downtime,  plus  a  "rider"  that  no  more  than  a  fixed  small 
percent  of  repair  actions  should  exceed  some  predetermined  larger 
value  of  downtime. 

Technician  error  rate  is  a  key  variable  in  such  a  specification,  since 
it  represents  the  combined  effects  of  technician  experience,  training, 
aptitudes,  and  prescribed  procedures.  In  fact  it  is  possible  that  re¬ 
search  will  show  that  the  error  rate  has  a  strong  bearing  in  the 
determination  of  the  most  appropriate  downtime  distribution,  thus 
resolving  a  current  controversy  between  proponents  of  the  lognormal 
on  the  one  hand  and  the  exponential  on  the  other. 

It  also  appears  reasonable  that  technician  error  rate,  at  some  future 
time,  can  be  made  as  explicit  a  system's  requirement  as  downtime. 
Considerable  research  will  be  necessary,  however,  to  correlate 
error  rate  with  factors  such  as  design  requirements  and  technician 
proficiencies.  Psychological  problems  in  obtaining  accurate  data 
on  this  factor  are  also  recognized. 

To  return  to  our  basic  thesis — Figure  5  schematically  breaks  the 
downtime  requirement  for  our  example— a  typical  modularized  fire 
control  system, into  its  basic  functional  elements  such  as  detection, 
diagnosis,  correction  and  check.  In  order  to  meet  system  require¬ 
ments,  downtime  goals  must  be  allocated  at  least  to  these  functional 
elements  at  the  system,  subsystem  and  module  levels. 

At  present,  insufficient  data  exist  on  most  operational  systems  to 
determine  the  contribution  to  downtime  of  these  basic  elements. 
Further,  for  developmental  systems,  techniques  are  just  beginning 
to  evolve  which  will  permit  prediction,  from  the  design  configuration. 
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of  the  expected  contribution  of  each  of  these  elements  to  total  down¬ 
time.  ^ 

The  ability  to  predict  these  elements  of  downtime  at  the  design  stage 
is  fundamental  if  maintainability  is  to  become  a  quantitative  design 
parameter.  Reliability  was  at  a  comparable  stage  of  development 
about  a  decade  ago.  It  required  considerable  research,  planning 
and  testing,  plus  data  gathering  and  analysis,  to  reach  the  present 
stage  wherein  component  and  system  reliability  can  be  predicted 
within  satisfactory  accuracy  at  the  design  stage.  Maintainability 
can  move  more  rapidly  to  a  similar  level  by  drawing  on  experience 
and  techniques  from  the  reliability  engineering  field.  The  funda¬ 
mental  need,  of  course,  is  derivation  of  predictive  data  through 
properly  planned  and  controlled  programs.  Requirements  are 
meaningless  to  the  design  engineer  unless  there  are  predictive 
methods  available  to  assist  him  in  designing  to  meet  them.  Know¬ 
ledge  of  the  accuracy  of  these  methods  is,  of  course,  also  a  pre¬ 
requisite  . 

It  is  a  two-pronged  problem — the  need,  on  the  one  hand,  to  state 
requirements  quantitatively  and  explicitly  and  to  allocate  them  to 
specific  functional  equipment  groupings  the  designer  works  with  — 
the  need,  on  the  other  hand,  to  be  able  to  predict,  at  the  design 
stage,  the  capability  of  these  functional  groups  to  meet  the  imposed 
requirements , 


SPECIFICS  OF  MAINTAINABILITY 

We  have  now  reached  the  point  where  we  have  developed  quantitative 
'^downtime*’  or  "return  to  service"  requirements  for  our  hypotheti¬ 
cal  system.  These  requirements  have  been  derived  from  the  custo¬ 
mers  stated  equipment  mission  and  have  been  evaluated  from  a  cost- 
effectiveness  viewpoint  through  tradeoff  studies  which  consider  total 
system  costs,  including  RfcD,  manufacturing,  operation,  mainte¬ 
nance  and  logistics  over  the  life  of  the  system. 

Thus  far,  we  have  attempted  to  place  the  subject  area  of  maintain¬ 
ability  in  a  systems  context.  Just  as  reliability  is  a  field  unto  it¬ 
self,  requiring  its  own  specialties  in  terms  of  analysis  of  redundancy 
or  quality  of  components  and  parts,  maintainability  has  its  own  unique 
and  even  more  diversified  elements.  The  downtime  criterion  is  the 
effect  of  the  combined  interactions  of  numerous  discrete  elements 
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which  may  be  grouped  under  ’’design”,  ’’maintenance  policy”,  or 
’’technician  requirements”  as  alternative  means  for  the  support  of 
a  system. 

Figure  6  presents  some  of  the  variables  that  go  into  ’’maintain- 
ability”.  The  problem  of  designing  for  maintainability  involves 
weighing  and  evaluating  the  elements  of  what  the  designer  controls 
during  the  design  stage  (e.  g.  ,  module  size,  test  and  checkout  al¬ 
ternatives)  relative  to  the  maintenance  policy  alternatives  (echelon 
of  repair,  repair -discard)  which  may  or  may  not  be  appropriate  for 
the  system.  Additionally,  as  indicated  in  Figure  6,  the  design 
decision  should  be  made  in  the  manner  that  also  fits  the  availability 
and  capability  of  maintenance  personnel  as  they  may  be  allocated 
throughout  the  support  system. 

Relative  to  Figure  6,  there  are  many  tradeoffs  and  alternatives  in¬ 
volved  in  design,  maintenance  policies  and  technician  capabilities. 
Aside  from  the  effect  on  system  reliability  and  system  availability 
which  a  design  decision  can  have,  the  interrelationship  among  the 
elements  making  up  the  subject  area  of  maintainability  is  such  that 
a  change  in  one  or  more  will  have  an  effect  on: 

1.  The  duration  of  system  failure. 

2.  The  duration  of  a  component  failure. 

3.  The  system  cost  initially  and  over  its  lifetime  of  use. 

The  objective  of  a  systems  evaluation  model  (conceptually  shown  in 
Figure  6)  is  to  determine  the  effect  of  the  downtime  of  a  system  on 
system  availability  relative  to  costs.  High  system  availability 
specifications  in  complex  systems  place  a  requirement  on  rapid 
detection  to  some  functional  level  less  than  the  system  level  —  at  a 
cost.  Replacement  of  a  failed  module  at  an  operational  level  in¬ 
creases  system  availability  but  raises  the  cost  of  spares.  Whether 
to  repair  the  component  at  the  operational  level,  discard  it,  or  ship 
it  back  for  repair,  requires  a  comparison  of  alternatives  on  the 
basis  of  cost  and  effectiveness.  If  the  decision  is  to  repair,  the 
design  of  the  component,  the  technician  capability,  and  the  echelon 
at  which  the  repair  is  made,  all  influence  the  mean  downtime  (in 
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Figure  6.  Typical  Elements  of  Maintainability 
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which  detection  and  diagnosis  of  the  failure  may  now  be  a  major 
contributor) 

ALLOCATION  OF  M  REQUIREMENTS 

At  this  point  we  can  discuss  details  involved  in  allocating  system 
downtime  requirements  to  the  subsystem  and  module  level,  and  dis* 
cuss  some  of  the  intra  M  facets  of  the  complex  maintainability 
field 

Decisions  as  to  the  division  of  requirements  among  the  four  major 
elements  of  downtime  requires  detailed  cost  studies.  If  we  assume 
that  meeting  system  downtime  requirements  means  that  we  in  fact 
do  meet  specified  mission  requirements,  then  the  allocation  prob* 
lem  becomes  strictly  an  economic  one—i.e.,  attaining  the  specified 
downtime  capability  at  minimum  cost. 

One  of  the  primary  means  for  reducing  system  downtime  is  to  sub¬ 
stitute  automatic  checkout  and  diagnostic  equipment  for  the  slower 
human  operator  and  to  use  modularized,  plug  in  components. 
Decisions  to  automate  are  generally  made  on  a  systems  basis,  the 
level  to  which  automation  would  be  carried  (e.  g.  ,  automatic  fault 
isolation  to  a  replaceable  module  level)  would  be  determined  by 
cost  tradeoff  studies.  Results  would  establish  consistent  guide 
lines  for  allocating  downtime  requirements  below  system  level  to 
the  subsystem  and  the  component  level 

The  allocation  procedure  from  this  point  on  can  best  be  described 
by  a  hypothetical  example: 

Given  a  system  mean  downtime  requirement  of  ten  minutes  for 
failure  correction  and  given  also  that  no  more  than  two  maintenance 
actions  out  of  a  hundred  should  result  in  downtime  exceeding  30 
minutes.  The  former  means  we  have  ten  minutes  to  be  allocated 
among  the  various  elements  of  downtime: 

Note  that  downtime  is  of  prime  importance  at  the  operational  level 
relative  to  the  requirements  of  the  mission  (and  operational  avail¬ 
ability).  Downtime  in  supporting  echelons  can  generally  be  con¬ 
verted  to  cost  by  taking  into  account  such  factors  as  man  hours, 
required  facilities,  and  perhaps  most  important,  tradeoffs  be¬ 
tween  costs  of  items  in  the  supply  pipeline  versus  item  downtime 
(i.e.,  extra  spares  are  needed  to  support  a  repair  cycle  with  low 
output  per  unit  time). 
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The  most  time-consuming  element  of  downtime  is  generally  diagnosis. 
However,  substitution  of  automatic  diagnostic  equipment  and  proper 
selection  of  the  module  size  to  which  the  failure  will  be  isolated  can 
reduce  this  time  almost  to  zero.  The  same  holds  true  for  detection 
and  verification,  depending  on  the  extent  of  automation  desired.  This 
leaves  the  "correction*'  element  as  the  one  which  ultimately  becomes 
the  most  limiting  factor  in  this  example. 

For  our  example,  therefore,  we  could  assign  one  minute  for  detection 
and  two  minutes  for  diagnosis  to  module  level.  This  would  leave 
seven  minutes  to  be  allocated  between  verification  and  corrective 
action.  Since  the  same  test  circuitry  used  for  "detection"  could  be 
designed  to  conduct  automatic  verification  checking,  we  could  assign 
one  minute  to  the  latter — leaving  six  minutes  for  taking  correction 
action  (i.  e.  ,  removing  module,  obtaining  replacement,  installing  the 
replacement). 

Cost  tradeoffs  might  indicate  that  it  would  be  cheaper  to  go  to  re¬ 
dundant  switch-in  spares,  thus  reducing  corrective  time  and  elimi¬ 
nating  some  of  the  automatic  checkout  features.  This  is  but  one 
example  of  the  many  tradeoffs  necessary  to  determine  the  least  cost 
configuration. 

We  discussed  "expected"  or  mean  values  of  downtime  in  this  example 
to  make  the  point,  however  statistical  techniques  now  being  used  in 
other  design  problems  appear  appropriate  to  handle  the  specified  down¬ 
time  distribution  and  variance  (as  well  as  maximum  permissible  down¬ 
time  and  percent  of  its  occurrence. 

INTRINSIC  VERSUS  OPERATIONAL  M 

So  far,  we  have  been  discussing  the  intrinsic  or  designed-in  level  of 
M.  The  designer  or  systems  engineer  can  be  made  responsible  for 
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attaining  this  level.  He  cannot,  of  course,  be  held  responsible  for 
administrative  or  waiting  time  delays  that  occur  during  field  oper¬ 
ation.  Neither  can  he  be  responsible  for  anticipating  any  unspeci¬ 
fied  environmental  conditions  under  which  the  equipment  might 
operate  which  would  degrade  performance  and  increase  repair  time. 

For  this  reason,  the  system  downtime  requirements,  as  derived 
from  mission  requirements,  need  to  be  modified  to  provide  for  this 
less  than  100  percent  efficiency  in  the  field;.  ''K"  factors  must  be 
eventually  derived  to  permit  this  "derating"  of  downtime  require¬ 
ments 

The  inherent  downtime  capability  as  measured  under  ideal  conditions 
in  a  test  program  would  represent  the  maximum  attainable  by  the 
equipment.  The  derating  factor  then  is  necessary  for  field  use  be¬ 
cause  of  the  environment,  inefficiencies  of  qperation,  and  pressures 
of  the  tactical  situation. 


RECAPITULA  TION 

In  this  discussion  we  have  stressed  a  philosophy  of  approach  and  a 
method  for  deriving  certain  (not  all  inclusive:')‘^specific  maintain¬ 
ability  design  requirements.^  We- have  in-particular  emphasized- the 
importance  of  matching  M  requirements  to  mission  objectives 
through  the  connecting  link  of  system  downtime/^  It  should  be  noted 
in  closing  that  the  approach  to  the  M  requirements  problem  des¬ 
cribed  in  this  paper  is  just  a  beginning — further  research  is  needed 
to  become  intelligent  enough  to  translate  downtime  as  well  as  other 
M  characteristics  into  definitive  design  criteria 

A  work  of  caution  —  M  requirements  have  evolved  rapidly  in  a  mat¬ 
ter  of  months  from  being  completely  non-existent  to  being,  in  some 
cases,  elaborate  detailed  specifications.  A  serious  danger  exists 
that  overspecification  of  details  and  data  requirements  on  the  part 
of  the  military  customer  will  inhibit  this  necessary  future  research. 
Some  of-our  current  specifications,  while  performing  a  real  advance 
by  quantifying  M^— restrict  the  military  contractor  significantly  in 
his  latitude  of  approaches  to  solving  the  M  problem. 


Research  is  necessary  to  establish  values  for  such  factors  for 
different  kinds  of  equipment. 
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It  is  desirable  that  a  contractor  should  be  asked  to  develop  tools, 
such  as  predictive  system  models,  early  in  the  R&D  stage  of  a  new 
weapons  system;  it  is  probably  not  desirable  to  dictate  detailed  M 
data  requirements  and  analytical  techniques  at  this  early  stage. 
Rather  the  contractor  should  be  required  to  meet  broad  system  re¬ 
quirements,  should  be  given  maximum  flexibility  to  do  so,  and 
should  be  held  rigidly  accountable  for  his  final  performance. 
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